IEEE 1588 PTP [1][2] is now one of the industry accepted protocols for delivering high accuracy time services in the sub-microseconds levels. IEEE 1588 PTP is similar in concept to the Network Time Protocol (NTP) [3]. Both protocols distribute time messages over a packet network to time clients. NTP is ubiquitous and operates at the upper layers of the protocol stack and in its current form provides no better than millisecond levels accuracy. IEEE 1588 PTP is a layer 2 protocol (although it can also be made to operate over higher protocol layers) with hardware timestamping capabilities to provide sub-microsecond accuracy. As a packet-based high accuracy synchronization protocol, IEEE 1588 PTP certainly has a number of advantages over GPS, which until now was the only available solution for high quality time synchronization.
GPS based satellite receivers 16 provide sub-100 nanosecond accuracies, and are often used where precision time synchronization is mission critical: in telecommunication, military, and aerospace applications. But improved accuracy comes at a cost. GPS receivers used for telecom networks synchronization have a much higher specification (high quality oscillators, high holdover capability accuracies, etc.) than those in the average portable satellite navigation system, plus they need all the correct interfaces and cabling to communicate with the telecoms equipment. GPS based systems require outdoor antenna installations to assure a direct view of the sky to receive the low power satellite transmissions, which are not only an added expense but which create an extra burden on the physical infrastructure of the facility. For this reason, GPS is best suited to be used in a central location as the primary reference clock (PRC) for a telecom network with other technologies utilized to distribute synchronization and timing to remote locations.
GPS-based solutions also have poor or no reception in indoor and underground environments, and dense urban canyons where direct visibility of the GPS satellites 18 is poor thus making them not suitable for a good proportion of picocell and femtocell users. GPS is also not suitable for devices with small footprints requiring time synchronization like wireless sensors. Another concern is GPS is perceived outside the USA as an American controlled technology with no service guarantees (GPS is not autonomous), as a result its use as the primary source of timing is not favored by operators in other countries. For the above reasons, IEEE 1588 PTP has gained traction in the industry as the protocol of choice for high quality synchronization.
Clock Synchronization in Packet Networks
The need for synchronized time is critical for today's network environments. FIG. 1 shows a general view of some of the devices that require time synchronization in a packet network 12. The time transfer protocol could be NTP or IEEE 1588 PTP, but the latter is the protocol of choice for telecom networks.
There are many applications of high precision time synchronizations, some of which are emerging applications. Some notable application areas are as follows:                Mobile Networking: Synchronization is a key requirement in the telecommunications industry and this market has become a driving force in the development and evolution of synchronization solutions and standards. For example, wireless technologies like GSM, WCDMA (both frequency division duplexing (FDD) and time division duplexing (TDD) technologies), and CDMA2000 require frequency accuracy of 0.05 ppm (parts per million) at the air interface. In addition, CDMA2000 requires time synchronization at the ±3 μs level (±10 μs worst case) and WCDMA TTD mode requires accuracy of ±1.25 μs between base stations. The accurate reference clock is typically derived from Time Division Multiplexing (TDM) interfaces (for GSM, WCDMA and other FDD based technologies) or from expensive GPS receivers located at the base station (for TDD based technologies). Without synchronization traceable to a highly accurate reference clock in the wireless network, local interference between channel frequencies, as well as mutual interference with neighboring base stations will occur. This could ultimately cause calls to be dropped and a degradation of the overall user experience. The high level of synchronization provided by IEEE 1588 PTP could also be useful in time-of-arrival (TOA) and time-difference-of-arrival (TDOA) based localization solution where one is interested in locating mobile nodes connected to a wireless network.        Residential Audio/Video (A/V) Networking: Modern consumer electronics now gather, store, and transmit audio and video data in digital form and require adequate quality of service and synchronization for live streaming. The 802.1AS protocol, which is based on IEEE 1588, provides timing and synchronization within bridged home A/V Ethernet LANs. The protocol allows high level timing information to be distributed to each media playback device, thus, providing them with a precise reference point for streaming multimedia. This synchronization technology, thus, enables a convergence to Ethernet as a viable consumer electronics interconnect.        Test and Measurement: IEEE 1588 PTP was originally designed to satisfy the need for synchronization in test and measurement systems but has now become beneficial in other areas. The challenge was to synchronize networked measuring devices with each other in terms of time so that they are able to record measured values and provide them with a precise system timestamp. Based on this timestamp, the measured values can then be correlated with each other.        Industrial Automation: The major uses of high precision synchronization within an industrial automation and motion-control environment are for sequencing event measurements, scheduling outputs, synchronizing actuation, timestamping logged data and coordinating events with a GPS level accuracies. Multi-stand printing presses which operate at very high speeds require a very high level of synchronization. By distributing highly precise timing information to each subsystem, a common point of reference can be used to coordinate their activities—each manufacturing component has a precise time reference to begin or end their associated actions.        
Other application areas include synchronization of sensors and sensor network, power systems, ranging, telemetry and navigation systems. Synchronization is also needed in other areas, though the level of accurate may not be as high as in the application areas cited above. Some general applications of synchronized time services are as follows:                Wireless sensor networks (WSNs): WSNs have a wide range of applications including the monitoring of the status of industrial processes and equipment, environmental monitoring, infrastructure monitoring, surveillance, tracking, etc. But the efficient operation of a WSN depends on how well the various nodes are time synchronized. Time synchronization allows for the coordination among the nodes for power saving sleep/wake up modes, localization of sensor nodes and other sources, data fusion, object tracking, transmission scheduling among the nodes, and distributed communication and processing of data.        Billing services: Billing services and similar applications must know the time accurately. Time based billing as in telecom networks rely on time synchronization. Mobile user billing and maintenance functions also rely on precise timing references.        Log file accuracy, auditing, and monitoring: Tracking security breaches, network usage, or problems affecting a large number of components can be nearly impossible if timestamps in logs are inaccurate.        Network fault diagnosis and recovery: Every aspect of managing, securing, planning, and debugging a network involves determining when events happen. Without time synchronization, it can be difficult or impossible to correlate the time sequence of events involving multiple network components, such as outages, bugs, security breaches, service problems, or network problems. Precise timestamping of data events through each element in the backhaul network facilitates the isolation and traceability of failures and outages.        File timestamps: To reduce confusion in shared filesystems, it is crucial for the modification times to be consistent, regardless of what machine the filesystems are on. Sorting email and other network communications can also be difficult if timestamps are incorrect.        Access security and authentication (e.g., Kerberos): Many security and authentication protocols require accurate time synchronization. Applications such as cyptographic key management and secure document transmission may require using accurate, encoded timestamps which match unencoded time stamps to help assure document authenticity.        Real-world time values (e.g., correlation of events at different locations): In addition, interactions with dynamic events such as stock market trades, aviation management, and radio and TV programming, require careful synchronization of time among the various players in the system.        Validation of e-commerce transactions (e.g., electronic payments, electronic stock transfers): Some financial services even require highly accurate timekeeping by law.        Directory services (e.g., Active Directory, etc.)        Distributed computing        Scheduled operations (e.g., cron jobs, network backups)        Network forensics        
The following basic definitions will be used throughout this specification:                Clock Offset: The clock offset at a particular moment is the difference between the time reported by the time client (slave) and the “true” time as reported by the time server (master).        Clock Skew: A clock's skew at a particular moment is the frequency difference (first derivative of its offset with respect to true time) between the client clock and the server clock.        
Clock synchronization has received considerable attention over the last several years as the communication networks evolve from circuit-switched to all-IP packet based networks. With this migration the challenge of frequency and time synchronization has surfaced. The techniques in the state of the art differ by the assumed model and the estimated parameters.
The first group assumes that the two clocks differ by an offset. As a result the algorithms and techniques attempt to estimate only the offset between the clocks. The reality is far from this model, however, and as a result the second group adopts a more realistic model where the clocks differ by an offset and a skew. The skew is assumed constant in the duration of the estimation process. In order to achieve robust and accurate synchronization, advanced algorithms are needed that estimate the offset and skew simultaneously.
Clock synchronization over packet networks (LANs) but with the offset only assumption has been proposed in [4] and [5]. The former implements offset estimation using IEEE 1588 protocol which is more accurate than the latter that uses the Network Time Protocol (NTP)—which is software-based, inaccurate time-stamping method.
The importance of clock synchronization in telecommunication networks has been highlighted in [6] where a phase control loop has been proposed using the IEEE 1588 PTP protocol to estimate the offset. Another recent offset-only clock synchronization algorithm has been proposed in [7] which follows [6] in concept where the PTP algorithm is used as the timestamp exchange mechanism and a PLL is implemented to estimate the offset. In addition the authors propose noise reduction mechanisms to deal with Packet Delay Variation (PDV) noise typically experienced in packet networks.
The problem with all these techniques is the non-realistic assumption that the two clocks differ only by an offset. The reality however is that the slave clock, in addition to the offset, deviates in time as well due to the skew problem which is an inherent problem with most clocks. As a result in order to enable robust and accurate synchronization both the offset and the skew should be estimated.
There are several techniques that propose clock synchronization algorithms to estimate the skew through linear regression or linear programming techniques and convex hull methods.
Specifically, [8] proposes a median line-fitting technique which is a robust line-fitting technique. The problem with line-regression algorithms is that they are usually not robust to presence of large outliers and thus the robustness is only valid for certain PDV models (e.g. Gaussian).
In [9] a simple skew and offset estimation method is proposed where timestamps are used to compute the average jitter and average inter-packet arrival time. Then the relative skew is computed as the ratio of the average jitter to the average inter-packet time.
A more complicated approach is proposed in [10] [11] where a linear programming technique is used to estimate the clock skew in network delay measurements. The technique shows improvement in performance compared to other existing algorithms.
In [12] [13] skew estimation is achieved through the computation of convex hull from the delay measurements. The authors claim that convex-hull approach provides better insight and handling of error metrics compared to linear regression or linear programming techniques. Although the technique was tested using NTP, it can be implemented with any protocol (such as IEEE 1588) that captures the delay measurements.
An extension of this technique is introduced by [14] where both the offsets and skew are estimated by a lower and upper convex hull approach that relies on using forward/backward delay measurements.
An adaptive approach to estimating the clock skew was proposed in [15] where a recursive least squares approach is used to calculate an estimate of the clock skew.
One major drawback of these techniques is that they have been developed using NTP messaging mechanisms which does not have high accuracy. For very precise clock synchronization applications such as synchronizing TDD base stations over packet network a more robust approach is required that integrates IEEE 1588 protocol.
IEEE 1588 Precision Timing Protocol (PTP)
IEEE 1588 PTP was defined [1][2] to synchronize distributed clocks across Ethernet and other packet based networks. It allows for synchronization of distributed clocks to sub-microsecond accuracy. IEEE 1588 PTP was designed as an improvement to current time synchronization technologies such as the network time protocol (NTP) [2]. NTP allows for synchronization of distributed clocks to a precision in the order of hundreds of microseconds or milliseconds, which for many applications such as those for personal computing purposes is a sufficient level of accuracy. IEEE 1588 PTP, which is now the industry accepted standard for synchronization, grew out of the need for greater accuracy synchronization over packet networks, particularly Ethernet.
IEEE 1588 PTP relies on the use of hardware timestamped messages to synchronize one or more slave clocks (time client) to a master clock (time server). This process involves a message transaction between the master and slave where the precise moments of transmit and receive are measured, preferably at the hardware level. Accurate time information is distributed hierarchically, with a grandmaster clock at the root of the hierarchy. The grandmaster provides the time reference for one or more slave devices. These slave devices can, in turn, act as master devices for further hierarchical layers of slave devices.
IEEE 1588 PTP also defines the descriptors that characterize a clock, the states of a clock and the allowed state transitions. The standard defines network messages, fields and semantics, the datasets maintained by each clock and the actions and timing for all IEEE 1588 network and internal events. In addition, the standard describes a suite of messages used for monitoring the system, specifications for an Ethernet-based implementation and conformance requirements and some implementation suggestions.
IEEE 1588 PTP relies on the transfer of PTP messages to determine clock and system properties and to convey time information. A delay measurement process is used to determine path delays, which are then accounted for in the adjustment of local clocks. At system start up, a master/slave hierarchy is created using the Best Master Clock (BMC) algorithm [1] to determine which clock has the highest quality clock (grandmaster clock) within the network. The BMC algorithm is then run continuously to allow clocks to adjust quickly to changes in network configuration and status. If the grandmaster clock is removed from the network or is determined by the BMC algorithm to no longer be the highest quality clock, the algorithm then redefines what the new grandmaster clock is and all other clocks are adjusted accordingly.
Synchronization with IEEE 1588 PTP is achieved using a series of message transactions between a master and its slaves. FIG. 2 shows the message flow process for a strictly peer-to-peer message transaction scenario. This figure illustrates the case where the master clock in a time server 10 is directly attached (or peered) to a slave clock in a time client 14 over a packet network 12. The slave clock derives its timing from the upstream master clock and then acts as a master clock for further downstream devices. The main time synchronization related message types for this exchange involve the Sync, Follow_Up, Delay-Req, and Delay_Resp messages. Other more complex message flow process where message traverse intermediate nodes are described in the IEEE 1588 PTP standard.
In FIG. 2, the master sends a Sync message to the slave and notes the time, T1, at which it was sent. The slave receives the Sync message and notes the time of reception, T2. The master conveys to the slave the timestamp T1 by either embedding the timestamp T1 in the Sync message (i.e., one-step clock mode which requires some sort of hardware processing for embedding the timestamp on-the-fly for highest accuracy and precision), or embedding the timestamp T1 in a Follow_Up message (i.e., two-step clock mode). The slave sends a Delay_Req message to the master and notes the time, T3 at which it was sent. The master receives the Delay_Req message and notes the time of reception, T4. The master conveys to the slave the timestamp T4 by embedding it in a Delay_Resp message. The use of Follow_Up messages eliminates the need to timestamp transmitted messages on the fly, thereby facilitating a simpler hardware implementation.
After this message exchange the slave will have four timestamps {T1, T2, T3, T4} from which it can determined both the network delay, d, (the time taken for messages to traverse the network link between the two nodes) and the slave offset, θ, (time offset by which the slave clock leads or lags the master). Messages containing current time information are adjusted to account for their path delay, therefore providing a more accurate representation of the time information conveyed. Under the assumption that the delays for the two paths are symmetric (the delay in one direction is the same as the delay in the opposite direction), the following relationships can be derived (see FIG. 2):X=T2−T1=θ+d  (1)Y=T4−T3=−θ+d  (2)
From these equations, the slave computes the fixed delay d and clock offset θ, as follows:
                    d        =                                                            (                                                      T                    2                                    -                                      T                    1                                                  )                            +                              (                                                      T                    4                                    -                                      T                    3                                                  )                                      2                    =                                    X              +              Y                        2                                              (        3        )                                θ        =                                                            (                                                      T                    2                                    -                                      T                    1                                                  )                            -                              (                                                      T                    4                                    -                                      T                    3                                                  )                                      2                    =                                    X              -              Y                        2                                              (        4        )            
The clock offset θ can be used to align the local clock to the master's. A key assumption here is that the message exchanges occur over a period of time so small that the offset θ can be assumed constant over that period. In addition, the accuracy of this link delay measurement depends on both the symmetry of the one-way link delays and the accuracy of the timestamping process.
A complete IEEE 1588-based solution at a time client includes servo algorithms, filters, PTP-Clock based on hardware timer and direct timer access. IEEE 1588 defines a wide range of synchronization capabilities except the clock synchronization mechanisms (servo algorithm, PLL, timers, etc.) to be used at the receiver (slave) to synchronize its local clock to the master. Methods of clock adjustment implementation are not specified by IEEE 1588—it only provides a standard protocol for the exchange of messages between clocks. The benefit of not specifying clock adjustment implementations, is to allow clocks from different manufactures to be able to synchronize with each other as long as they understand the messaging protocol.
There are a number of factors that can cause two supposedly identical clocks to drift apart or lose synchronization. Differences in temperature, the age of the oscillators themselves, manufacturing defects and material variations in the manufacturing process, and electric and magnetic interference, among other factors, can all affect the quality of synchronization.
Even the smallest errors in keeping time can significantly add up over a long period. If a clock frequency (skew) is off by just 10 parts per million (ppm), it will gain or lose almost a second a day (i.e., 24×60×60/105=0.86 s/day). All of these factors create a need for clock synchronization to allow for two clocks to be aligned when differences occur. The continuous variations of the above factors also explain why the process of synchronization is continuous and not a one-time process. Clearly, having any sort of meaningful time synchronization is almost impossible if clocks are allowed to run on their own without synchronization.
The above simple analysis shows that clock skew is the main reason why clocks drift apart and need to be aligned periodically. The analysis shown earlier based on FIG. 2 does not explicitly consider clock skew in the system. Adjusting for the clock skew in addition to the initial clock offset guarantees the long term reliability of the synchronization process. Critical applications like those enumerated above require higher synchronization accuracy and reliability.
An object of the present invention is to achieve accurate and robust synchronization, preferably over IEEE 1588, for critical applications that require stringent synchronization margins.